REMARKS 

Applicant is in receipt of the Office Action mailed June 5, 2007. Claims 1, 27, 
and 28 have been amended. Claims 1-28 are pending in the case. Reconsideration of the 
present case is earnestly requested in light of the following remarks. 

Telephone Interview Summary 

On Tuesday, July 31, Applicant discussed independent claim 1 and the cited art 
with the Examiner, particularly, the terminology used in the claim and the Examiner's 
interpretation of the terms used. The Examiner suggested that Applicant amend the claim 
to clarify the nature of the graphical program node palette described. Regarding the 
section 101 rejection, Applicant explained the definitions and distinctions between the 
terms "medium", "carrier medium", and "memory medium" as described in the 
Specification, noting that "memory medium" is a subset of the other two, but not the 
converse, i.e., that "memory medium" does not include "carrier medium". The Examiner 
agreed, and suggested that this explanation be included, along with a clarifying 
amendment of claim 1, in a Response After Final, which Applicant agreed to do. 

Amendments 

Applicant has amended the claims as indicated above to clarify the scope of the 
claimed invention, and respectfully submits that the claims as currently written are 
patentably distinct from the cited art. Applicant has also amended the Specification to 
correct the cited informalities, and requests removal of the objection to the Specification. 

Section 101 Rejections 

The Office Action rejected claims 1-18 as being directed to non-statutory subject 
matter, asserting that Applicant's definition of "memory medium" includes "carrier 
medium". Applicant respectfully disagrees. 

As clearly defined in p. 13-14 of the Specification: 

Memory Medium - Any of various types of memory devices or storage 
devices. The term "memory medium" is intended to include an 
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installation medium, e.g., a CD-ROM, floppy disks 104, or tape device; a 
computer system memory or random access memory such as DRAM, 
DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; or a non-volatile 
memory such as a magnetic media, e.g., a hard drive, or optical storage. 
The memory medium may comprise other types of memory as well, or 
combinations thereof. In addition, the memory medium may be located in 
a first computer in which the programs are executed, or may be located in 
a second different computer which connects to the first computer over a 
network, such as the Internet. In the latter instance, the second computer 
may provide program instructions to the first computer for execution. The 
term "memory medium" may include two or more memory mediums 
which may reside in different locations, e.g., in different computers that 
are connected over a network. 

Carrier Medium - a memory medium as described above, as well as 
signals such as electrical, electromagnetic, or digital signals, conveyed via 
a communication medium such as a bus, network and/or a wireless link. 

Medium - includes one or more of a memory medium, carrier medium, 
and/or programmable hardware element; encompasses various types of 
mediums that can either store program instructions / data structures or can 
be configured with a hardware configuration program. 

As may be seen, these three terms are hierarchical, with "medium" being the 
broadest, "carrier medium" being the next broadest, and "memory medium" being the 
least broad. More specifically, a memory medium is defined as a subset of carrier 
medium, which is itself a subset of medium. For example, note that the definition of 
"carrier medium" includes "a memory medium as described above, as well as signals 
such as electrical, electromagnetic, or digital signals". Thus, Applicant respectfully 
submits that carrier medium includes memory medium, but that memory medium does 
not include carrier medium. 

Applicant respectfully requests removal of the section 101 rejection of claims 1- 

18. 

Section 102 Rejections 

Claims 1-18 and 26 were rejected under 35 U.S.C. 102(e) as being anticipated by 
Zink et al (US 6,738,964, "Zink"). Applicant respectfully disagrees. 
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As the Examiner is certainly aware, anticipation requires the presence in a single 
prior art reference disclosure of each and every element of the claimed invention, 
arranged as in the claim. Lindemann Maschinenfabrik GmbH v. American Hoist & 
Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention must be 
shown in as complete detail as is contained in the claims. Richardson v. Suzuki Motor 
Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

Amended claim 1 recites: 

1. A computer accessible memory medium comprising program instructions, 
wherein the program instructions are executable by a processor to implement: 

displaying a palette, including a display window comprising a plurality of 
graphical program nodes for use in a graphical program, wherein each graphical program 
node comprises an icon and program code, wherein each graphical program node is 
represented by the graphical program node's respective icon in the palette and is 
selectable from the palette for inclusion in the graphical program; 

wherein the plurality of graphical program nodes comprises: 

a first plurality of function nodes displayed in the display window, 
wherein each function node corresponds to a respective functionality; and 

a second plurality of property nodes displayed in the display window, 
wherein each property node corresponds to a respective one of at least a subset of the 
plurality of function nodes, wherein each property node is displayed proximate to said 
respective one of the at least a subset of the plurality of function nodes. 

Nowhere does Zink teach or suggest displaying a palette, including a display 
window comprising a plurality of graphical program nodes for use in a graphical 
program, wherein each graphical program node comprises an icon and program 
code, wherein each graphical program node is represented by the graphical 
program node's respective icon in the palette and is selectable from the palette for 
inclusion in the graphical program, as recited in claim 1 . 

The Office Action cites Figure 6, elements 602 and 603, and related text. 
Applicant respectfully notes that per Zink, 602 is a menu bar that "provides access to a 
set of drop-down menus that provide many useful functions like adding components to 
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the drawing, saving the drawing, and configuring the target hardware." Zink's mentioned 
drop-down menu that provides a function for adding components to the drawing is not 
equivalent to displaying a palette comprising a display window that includes a plurality 
of graphical program nodes for use in a graphical program. 

According to Zink, "Tool bar 603 provides a row of icon-buttons to permit rapid 
access to functions that are most commonly used. In this example, the tool bar functions 
from left to right are: new drawing, open a file, save the drawing, cut, copy, paste, add a 
component to the drawing, build, run, stop, reset the target hardware, add a probe, add an 
audio probe, and lastly, turn on the data viewer. It is common to provide more than one 
tool bar." {emphasis added) 

Applicant respectfully submits that providing a button on a toolbar for "adding a 
component" in no way teaches displaying palette that includes a display window that 
includes a plurality of graphical program nodes for use in a graphical program, where 
each graphical program node comprises an icon and program code, wherein each 
graphical program node is represented by the graphical program node's respective icon in 
the palette and is selectable from the palette for inclusion in the graphical program. For 
example, Applicant notes that in each of these examples (602, 603), no palette of function 
nodes is presented, but rather, a means for adding a component is referred to 
(specifically, a menu or toolbar button), but what exactly this "means" entails is not 
disclosed. For example, a user might invoke a file browser (via the menu or button) to 
browse directories that include files for the desired functionality or components. 
However, Zink is silent as to what activation of the menu item or button might invoke, 
and makes no mention of displaying a plurality of selectable graphical program nodes 
(icons with program instructions) for inclusion in a graphical program in a graphical 
program node palette. 

In the Response to Arguments, the Office Action asserts that Zink's toolbar and 
menu options are graphical program nodes for use in a graphical program. Applicant 
respectfully submits that those of skill in the art of graphical programming would readily 
understand that Zink's user-selectable functions (via toolbar or menus) are not graphical 
program nodes. Applicant has amended claim 1 as indicated above to clarify the 
meaning of graphical program nodes, and respectfully submits that Zink's toolbar and 
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menus in no way teach or suggest Applicant's claimed displayed graphical program node 
palette with graphical program nodes that are selectable for inclusion in a graphical 
program. In fact, Zink nowhere discloses a palette of graphical program nodes at all. 
The Office Action states that Zink's pull-down menu of functions is actually a display of 
function nodes, which Applicant respectfully submits is incorrect, since functions 
certainly need not be graphical program nodes. For example, the cited function "saving 
the drawing" is certainly not a graphical program node that may be included in a 
graphical program. Similarly, as noted above, Zink is silent as to the way new 
components may be added to the drawing, and makes no mention of a graphical program 
node palette at all. 

Thus, Zink fails to teach or suggest these features of claim 1 . 

Zink also fails to teach or suggest wherein the plurality of graphical program 
nodes comprises: a first plurality of function nodes displayed in the display 
window, wherein each function node corresponds to a respective functionality; and 
a second plurality of property nodes displayed in the display window, wherein each 
property node corresponds to a respective one of at least a subset of the plurality of 
function nodes, wherein each property node is displayed proximate to said 
respective one of the at least a subset of the plurality of function nodes, as recited in 
claim 1 . 

The Office Action cites 603 and 603 of Figure 6 and associated text, e.g., 
col.4: 12-23, and coll 1:52-60. 

As discussed above, 602 and 603 of Figure 6 (and their related descriptions in 
col.4: 12-23) in no way teach or suggest displaying a palette, including a display window 
comprising a plurality of graphical program nodes for use in a graphical program, where 
each graphical program node includes an icon and program code, and where each 
graphical program node is represented by the graphical program node's respective icon in 
the palette and is selectable from the palette for inclusion in the graphical program. 
Col. 11:52-60 of Zink describes several different types of components can be used in a 
drawing, e.g., software components, such as software designed to perform a pre-defined 
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task (e.g. a sine wave signal source), as well as other types of components, such as 
hardware components, platform components, framework components, annotation 
components, and intrinsic components. Nowhere does the cited text (or Zink in general) 
teach or suggest these claimed features. 

In asserting that Zink teaches a second plurality of property nodes displayed in 
the display window, wherein each property node corresponds to a respective one of 
at least a subset of the plurality of function nodes, wherein each property node is 
displayed proximate to said respective one of the at least a subset of the plurality of 
function nodes, the Office Action cites col. 1 1:60-67. Applicant respectfully notes that 
this text describes platform components that contain information about the target 
hardware where the project's executable code will be "run", e.g., the operating system or 
kernel. Again, nowhere does this text discuss such property nodes being displayed in a 
display window (of a palette), where each property node corresponds to a respective one 
of at least a subset of the plurality of function nodes, and where each property node is 
displayed proximate to the respective one of the at least a subset of the plurality of 
function nodes. Applicant notes that Zink's toolbar and menus are not palettes, nor are 
they described or characterized as such in Zink. Nor does Zink disclose property nodes 
being displayed proximate to respective corresponding function nodes in a palette. 

In the Response to Arguments, the Office Action cites Zink's toolbar and menu 
options, asserting that the selectable functions, such as "open file", "save the drawing", 
etc., are graphical program nodes, specifically, function nodes, which, as noted above, is 
incorrect. Applicant respectfully notes that Zink's selectable functions, including the 
"add component to drawing" function, are nowhere disclosed as graphical program nodes 
displayed in a palette that can be included in a graphical program. 

Similarly, the Office Action asserts that Zink's disclosed component properties 
are property nodes as recited in claim 1, which Applicant also respectfully submits is 
incorrect. Zink describes a number of different ways the properties of these components 
may be configured, but nowhere discloses respective individual property nodes 
corresponding to function nodes, and displayed proximate to those function nodes. For 
example, the cited "double-clicking on a block" to invoke a properties dialog box 
(col. 15:45-50) in no way discloses Applicant's claimed property nodes (displayed in a 



14 



palette), which are graphical program nodes (with an icon and program code) 
corresponding to respective function nodes, and which are displayed in the palette 
proximate to their respective function nodes. Nor are the other configuration means 
discussed in Zink, e.g., list-boxes, icons, drop-down lists, dialog windows, or wizards, 
ever described as graphical program property nodes displayed in a palette proximate to 
corresponding function nodes. The Office Action apparently has attempted to equate a 
wizard with a graphical program node, which Applicant respectfully submits is incorrect. 
A software wizard is not a graphical program node, as is well-understood by those of 
ordinary skill in the art of graphical programming. 

Thus, Zink also fails to teach or suggest these limitations of claim 1 . 

Thus, for at least these reasons, Applicant respectfully submits that Zink fails to 
teach or suggest all the features and limitations of claim 1, and so claim 1 and those 
claims dependent therefrom are patentably distinct and non-obvious over the cited art, 
and art thus allowable. 

Applicant respectfully submits that amended independent claims 27 and 28 
include similar limitations as claim 1 , and so the above arguments apply with equal force 
to these claims. Thus, for at least the reasons provided above, Applicant submits that 
claims 27 and 28, and those claims respectively dependent therefrom, are patentably 
distinct and non-obvious over the cited art, and art thus allowable. 

Removal of the section 102 rejection of claims 1-10, 12-13, and 15-18 is 
respectfully requested. 

Section 103 Rejections 

Claims 11 and 14 were rejected under 35 U.S.C. 103(a) as being unpatentable 
over Zink in view of Kellerman et al. (US 6,750,887 Bl, "Kellerman"). Applicant 
respectfully disagrees. 

As the Examiner is aware, if an independent claim is nonobvious under 35 U.S.C. 
103, then any claim depending therefrom is nonobvious. In re Fine, 837 F.2d 1071, 5 
USPQ2d 1596 (Fed. Cir. 1988). Because independent claim 1 has been shown above to 
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be patentably distinct and non-obvious, and thus allowable, dependent claims 11 and 14 
are similarly patentably distinct and non-obvious, and thus allowable. 

Additionally, Applicant respectfully submits that neither Zink nor Kellerman 
discloses all the features of these claims. For example, the Office Action asserts that 
Zink teaches wherein, in each property node being displayed proximate to the 
respective one of the at least a subset of the plurality of function nodes, each 
property node is displayed in a common row with the respective one of the at least a 
subset of the plurality of function nodes, as recited in claim 14, citing Figure 13:1502 
and associated text, col.l2:52-13:7, col.l3:57-col.l4:l, col.l5:45-50, and Figure 17B 
with associated text. 

Applicant respectfully notes that the Office Action did not address Applicant's 
arguments regarding claims 13 and 14, and respectfully requests that the Examiner either 
respond to these arguments, presented again below, or allow these claims. 

Applicant has reviewed the cited portions of Zink closely, and can find no 
description of these claimed features. For example, Figure 13:1502 and associated text 
discloses annotation components for annotating components in Zink's display, such as 
text boxes, dotted lines, labels, etc. More specifically, per Figure 13 and col. 12:52-13:7, 
element 1502 refers to a rectangle (shown in Figure 13) that the user may employ to 
indicate that a group of components has some common characteristic, and nowhere 
discloses a plurality of property nodes, each displayed proximate to a respective 
(corresponding) function node in a common row. 

Col.l3:57-col.l4:l discusses user access to property settings for components, and 
discloses various means for providing this access, including "list-boxes (very similar to 
FIG. 8C), icon-based graphical user interfaces, dedicated property dialog windows, and 
via "wizards" that prompt the user for performance-related information and then process 
the user inputs to determine actual property settings". Again, nowhere does this text (or 
the Figures) disclose the display in a palette of property nodes proximate to 
corresponding function nodes in a common row as claimed. 

Col. 15:45-50 discusses the user setting properties of each block on a drawing via 
a property dialog window as shown in Figure 17B, and nowhere describes display in a 
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palette of property nodes proximate to corresponding function nodes in a common row as 
claimed. 

Thus, Applicant respectfully submits that the cited portions of Zink, and Zink in 
general, fail to disclose these features of claim 14. 

The Examiner admits that Zink fails to disclose wherein, in each property node 
being displayed proximate to the respective one of the at least a subset of the 
plurality of function nodes, each property node is displayed in a common column 
with the respective one of the at least a subset of the plurality of function nodes, as 
recited in claim 14, but asserts that Kellerman remedies this admitted deficiency of Zink. 
Applicant disagrees, noting that the cited col.4:8-50 (and Figure 1) of Kellerman is 
directed to a GUI layout, specifically, rows and columns of GUI components, "such as 
text labels, buttons, combo boxes or text fields," etc. Applicant notes that these GUI 
components are not graphical program nodes, and more specifically are not function 
nodes and corresponding property nodes. Nowhere does the cited text, Figures, or 
Kellerman in general, disclose a plurality of property nodes, each displayed proximate to 
a respective (corresponding) function node in a common column in a palette. 

Thus, Applicant respectfully submits that Kellerman fails to teach or suggest these 
features of claim 14. 

Nor do Zink or Kellerman teach or suggest displaying primary and secondary 
function nodes in the display window in respective groups, where the primary set of 
function nodes is displayed in a first column in the display window and the secondary set 
of function nodes is displayed in a second column in the display window, as recited in 
claim 1 1 . 

Applicant submits that Zink and Kellerman are not properly combinable to make 
a prima facie case of obviousness, for at least the reason that a proper motivation to 
combine has not been presented. Applicant notes that the suggest motivation to combine: 
"to address the problem of laying out (i.e., organizing and displaying) visual components 
(graphical nodes) of a GUI in a pleasing arrangement with minimum developer effort" 
(Kellerman col. 3:35-52), is not germane to Applicant's invention as claimed. For 
example, Applicant submits that Kellerman's visual GUI components are not equivalent 
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to Applicant's graphical program nodes, which are nodes, specifically, function nodes 
and property nodes, for use in a graphical program, not GUI elements. 

Additionally, Applicant submits that Zink and Kellerman are not analogous art, at 
least for the reason that Kellerman is directed to GUI layout, which is not the same field 
of endeavor as graphical programming. More specifically, Kellerman teaches a simple 
graphical approach to specifying a GUI layout, which is not a graphical program. For 
example, nowhere does Kellerman teach or suggest, or even hint at, presenting selectable 
function nodes in a palette, and further presenting property nodes in the palette 
corresponding to these function nodes in the manner claimed. 

Thus, Zink and Kellerman are not properly combinable to make a prima facie case 
of obviousness. Moreover, even were Zink and Kellerman properly combinable, which 
Applicant argues they are not, the resulting combination would still not produce 
Applicant's invention as claimed, as argued at length above. 

Thus, for at least the reasons provided above, Applicant submits that Zink and 
Kellerman, taken singly or in combination, fail to teach or suggest all the features and 
limitations of claims 11 and 14, and so claims 11 and 14, and those claims respectively 
dependent therefrom, are patentably distinct and non-obvious over the cited art, and art 
thus allowable. 

Removal of the section 103 rejection of these claims is respectfully requested. 

Applicant also asserts that numerous ones of the dependent claims recite further 
distinctions over the cited art. However, since the independent claims have been shown 
to be patentably distinct, a further discussion of the dependent claims is not necessary at 
this time. 
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CONCLUSION 



In light of the foregoing amendments and remarks, Applicant submits the 
application is now in condition for allowance, and an early notice to that effect is 
requested. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above-referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. The Commissioner is hereby authorized to charge any fees which 
may be required or credit any overpayment to Meyertons, Hood, Kivlin, Kowert & 
Goetzel P.C., Deposit Account No. 50-1505/5150-81 100/JCH. 

Also filed herewith are the following items: 
1X1 Request for Continued Examination 
O Terminal Disclaimer 

O Power of Attorney By Assignee and Revocation of Previous Powers 
O Notice of Change of Address 
□ Other: 

Respectfully submitted, 

/Jeffrey C. Hood/ 

Jeffrey C. Hood, Reg. #35198 
ATTORNEY FOR APPLICANT(S) 

Meyertons, Hood, Kivlin, Kowert & Goetzel PC 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: 2007-08-17 JCH/MSW 
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